I think this can be an assertion. If the WASI functions don't do what they're documented to do, that's definitely going to cause undefined behavior. And environ_get is documented to return the environment string with the format key=value, right?

The documentation doesn't say anything. wasmtime returns it in key=value, wasmer returns argv[0] which is definitely a bug.

We have 2 choices here:

1. make the zig code assume the WASI host is correct and do a little bit of prediction about the specifications of the behavior (key=value) and allow host bugs to cause bugs in Zig code that uses them.
2. recognize and work around WASI host bugs & undocumented behavior.

Given that WASI is so brand new, my preference is (1). That means that we recommend Debug or ReleaseSafe builds for now - due to upstream/downstream bugs - and then work with the third party projects to get their bugs fixed / documentation clarified. We can point to the zig standard library and say "this is how we want to implement it, it will work like this if you fix the bug / clarify the docs".

I'm fine with this, but you might consider using std.mem.separate

Combining this and the other comment about assert, you could do this:

const line = std.mem.toSlice(u8, ptr);
var it = std.mem.separate(line, "=");
const key = it.next().?;
const value = it.next().?;

Done. This also cleanly handles wasmer.